<html>
<head><meta charset="utf-8"><title>Test references · t-compiler/rust-analyzer · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/index.html">t-compiler/rust-analyzer</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Test.20references.html">Test references</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="212607884"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Test%20references/near/212607884" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> vsrs <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Test.20references.html#212607884">(Oct 07 2020 at 19:30)</a>:</h4>
<p><span class="user-mention" data-user-id="133169">@matklad</span> </p>
<p>There are two features that I think would be nice to have in RA:</p>
<ul>
<li>A mechanism to search all related tests for a function (both unit, and integration)</li>
<li>Provide a code lens with test references and the ability to run them in one click. Perhaps showing statuses (succeed, running, failed) if it is possible to implement (as I remember, at least VSCode API does not allow updating code lenses dynamically).</li>
</ul>
<p>And there are two difficulties:</p>
<ul>
<li>relatively slow reference search</li>
<li>synchronous code lens support. That is, the lenses resolved asynchronously, but the places where they need to be shown calculated synchronously! So, adding a synchronous tests lookup can seriously slow down the UI, which is not good.</li>
</ul>
<p>The first problem is not so hard. We can use inverted n-gram index or inverted names (identifiers) index. I guess names index should work faster and would be quite enough as we do not need regex support. But I'll try both approaches.</p>
<p>The second one is more complicated. LSP allows to add CodeLens asynchronously, but RA does not use this ability, and to my mind, it requires significant internal changes to add it.</p>
<p>Do you have some thoughts \ ideas \ suggestions on this? Thanks.</p>



<a name="213006605"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Test%20references/near/213006605" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Test.20references.html#213006605">(Oct 12 2020 at 07:44)</a>:</h4>
<p>This all sounds reasonable!</p>
<p>As usual, if we hide the feature behind a feature toggle, we can refine the impl as we go, no need to make it super fast right of the bat. </p>
<p>On the first point: We should have trigram index for speeding up reference search, but it requires some engineering effort to implement. We also need to check if trigram index is what actually is slow. My hunch here is that the slow thing is actually the semantic resolve, so it might make sense to profile it. IIRC, there are some low hanging frutits in the semantic resolve space. For example, we coupld classify potential match by syntax (field access, method call, path, pattern) and use that for some syntax-but-not-semantics quick filtering. </p>
<p>I also think that we effectively are <em>already</em> doing reference search to show "n references" code lens? If so, than the additional cost seems to be negligible? </p>
<p>On the second point: havan't looked into this, but, if there are async code lens, we should land a refactor to enable them!</p>



<a name="213700019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Test%20references/near/213700019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> vsrs <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Test.20references.html#213700019">(Oct 18 2020 at 10:23)</a>:</h4>
<p>I'm sorry for the late reply.</p>
<blockquote>
<p>We also need to check if trigram index is what actually is slow.</p>
</blockquote>
<p>If I'm not mistaken at the moment we  do full text search every time for each reference. If so, this can be accelerated.  </p>
<blockquote>
<p>My hunch here is that the slow thing is actually the semantic resolve, so it might make sense to profile it.</p>
</blockquote>
<p>I'll try, though not sure that I know this part of the code good enough.   </p>
<blockquote>
<p>I also think that we effectively are already doing reference search to show "n references" code lens?</p>
</blockquote>
<p>Actually I just reused existing mechanism, the same is used by rename_reference, etc. It works fast enough for n-references search, even for big projects like RA itself. But it too slow for tests search. I have a prototype and it takes up to 4-7 seconds to find all tests on my notebook. I'm sure it might be much faster.   </p>
<blockquote>
<p>but, if there are async code lens, we should land a refactor to enable them!</p>
</blockquote>
<p>Perfect. Perhaps, this is where I should start.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>